<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
  <head>
    <title>Real-Time Event Channel Configuration</title>
    <!-- -->
  </head>

  <body>
    <CENTER>
    <h1>Real-Time Event Channel Configuration</h1>
    </CENTER>

    <H3>Configuring the Event Channel at Compilation Time</H3>

    <P>TAO's Real-Time Event Channel can be configured at compilation
      time to use a different payload than its default.  To do so
      there are several options:
    </P>

    <UL>
      <LI><P>To eliminate the <CODE>CORBA::Any</CODE> field in the
          event payload you should define the
          <CODE>TAO_LACKS_EVENT_CHANNEL_ANY</CODE>
          macro when invoking the IDL compiler.
          You can do as follows:
<PRE>
$ cd $TAO_ROOT/orbsvcs/orbsvcs
$ make TAO_IDLFLAGS=-DTAO_LACKS_EVENT_CHANNEL_ANY
</PRE>
        </P>
      </LI>
      <LI><P>Similarly you can eliminate the octet sequence field in
          the event payload using:
<PRE>
$ cd $TAO_ROOT/orbsvcs/orbsvcs
$ make TAO_IDLFLAGS=-DTAO_LACKS_EVENT_CHANNEL_OCTET_SEQUENCE
</PRE>
        </P>
      </LI>
      <LI><P>Finally you can provide your own event payload, to do
          this you should Replace the contents of the
          <CODE>RtecDefaultEventData.idl</CODE>
          and define some IDL structure named
          <CODE>RtecEventData</CODE>.
          For example, you could define you own event type as follows:
<PRE>
// Replace RtecDefaultEventData.idl with this:

struct RtecEventData
{
  sequence&lt;long&gt; my_event_payload;
};
</PRE>
      </LI>
    </UL>

    <H3>Run-time Configuration</H3>

    <P>The new implementation of the real-time event channel uses a
      factory to build all the objects and strategies it requires.
      The factory can be dynamically loaded using ACE Service
      Configurator, this is extremely convenient because the factory
      can also parse options in the Service Configurator script file.
    </P>

    <P>There are currently several implementations of the factory.
      <ul>
<li>The <em>default</em> factory supports all of
      the options below and most of the potential values, except as
      specifically indicated.
<li>
      The <em>sched</em> factory defines new option values as indicated
      below that allow the RTES to integrate with the Real-Time
      Scheduling Service.  Use of the <em>sched</em> factory requires
      that you link in the TAO_RTSchedEvent library.
<li>
        The <em>tpc</em> (thread per consumer) factory defines new
        options values as indicated below.  This
          strategy is similar to the MT dispatching strategy in that it
          separates the thread that receives the push() from a supplier
          from the thread that does the eventual push() to the
          consumer(s), but it differs from MT in that MT has a pool of
          threads pulling from a single queue and ultimately potentially
          servicing every consumer, whereas TPC has a queue for <em>each</em>
          consumer and, thus, a single thread dedicated to pushing to that
          consumer.  This insures that a badly-behaved consumer <b>CANNOT</b>
          have an adverse effect on the channel or supplier.<br>
        To use this new strategy you will have to replace the call in your code
          for <code>TAO_EC_Default_Factory::init_svcs()</code> with
          <code>TAO_EC_TPC_Factory::init_svcs()</code>.

<li>      The <em>basic</em> and <em>null</em> factories are hard-coded
      factories that do not support any configuration options.
      They both define simple configurations that may enable some
      applications to use the RTES in a smaller footprint.
      See the files
      <code>$TAO_ROOT/orbsvcs/orbsvcs/Event/EC_Null_Factory.h</code>
      and <code>$TAO_ROOT/orbsvcs/orbsvcs/Event/EC_Basic_Factory.h</code>
      for details.
    </ul>
    </P>

<h3>Special Topic: Queue Configuration</h3>
    <p>
      In certain configurations such as <em>mt</em> and <em>tpc</em>,
      the RTES implementation uses something called
      <code>TAO_EC_Queue</code>, which is an in-memory queue that
      separates threads that receive <code>push()</code> invocations
      from suppliers from the threads that dispatch
      <code>push()</code> invocations to consumers.  A user of the
      RTES can configure some behaviors of this queue as well as
      behaviors when the queue reaches certain trigger points.  The
      configuration of these behaviors is a combination of
      compile-time and run-time specification.
    </p>
    <p>
      The queue itself has two trigger points for the number of
      invocations in the queue:
      <ul>
      <li><em>low-water mark (LWM)</em>, a lower threshold below which the
      queue allows more invocations to be placed into the queue;
      <li><em>high-water mark (HWM)</em>, an upper threshold above which the
      queue prevents more invocations from being added to the queue
      </ul>
    The values for these can be set at compile time via
    <code>TAO_EC_QUEUE_LWM</code> and <code>TAO_EC_QUEUE_HWM</code>
    for the low-water mark and high-water mark, respectively.
    <p>
      In addition, an application can specify what the RTES should do if a
      queue reaches the HWM, i.e., fills up.  This behavior is encapsulated in a
      derivation of an <code>ACE_Service_Object</code>, called
      <code>TAO_EC_Queue_Full_Service_Object</code>.  The RTES looks
      for a service object of a particular name (the default for this
      name is in macro TAO_EC_DEFAULT_QUEUE_FULL_SERVICE_OBJECT_NAME,
      which is "EC_QueueFullSimpleActions") and invokes
      <code>queue_full_action()</code> on the instance.  See class
      <code>TAO_EC_Simple_Queue_Full_Action</code> in file
      <code>$TAO_ROOT/orbsvcs/orbsvcs/Event/EC_Dispatching_Task.h</code>
      for an example.  This particular example can be configured to
      either <em>wait</em> or <em>discard</em> new invocations on
      reaching the HWM.
    </p>

    <H3>The configuration file</H3>

    <P>The real-time event channel uses the same service configurator
      file that the ORB uses, the default name for this file is
      <CODE>svc.conf</CODE>, but the ORB option
      <CODE>-ORBSvcConf</CODE> can be used to override this.
      The format of the file is described in detail in
      the service configurator documentation, but the relevant section
      for the event channel looks like this:
    </P>

<PRE>
# Comments go here...
# More comments if you want to...
static EC_Factory "-ECFiltering basic ....."
# ...and optionally...
static EC_QueueFullSimpleActions "[wait | discard]"
# ...or you can define your own TAO_EC_Queue_Full_Service_Object,
#    give it whatever name you want and use -ECQueueFullServiceObject
#    (see below) to specify that object's service configurator tag.
</PRE>

    <p>
    The
      table below describes all of the options (and values) supported by
      these factories.
    <P>All the event service factory options start with
      <CODE>-EC</CODE></P>


    <H3>The options</H3>

    <P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0">
        <TR>
          <TH>Option</TH>
          <TH>Description</TH>
        </TR>

        <!-- <TR NAME="ECDispatching"> -->
        <TR>
          <TD><CODE>-ECDispatching</CODE>
            <EM>dispatching_strategy</EM>
          </TD>
          <TD>Select the dispatching strategy used by the real-time
            event service. The <EM>reactive</EM> strategy uses the
            same thread that received the event from the supplier to
            push the event to all the consumers.<br>
            The <EM>priority</EM> strategy (sched factory only) uses
            a prioritized pool
            of threads and queries the scheduling service to select
            the thread that dispatches each event.<br>
            The <EM>mt</EM> strategy also uses a pool of threads,
            but the thread to dispatch is randomly selected.<br>
            <b>Does not apply to the <em>tpc</em> factory.</b>
          </TD>
        </TR>

        <!-- <TR NAME="ECDispatchingThreads"> -->
        <TR>
          <TD><CODE>-ECDispatchingThreads</CODE>
            <EM>number_of_threads</EM>
          </TD>
          <TD>Select the number of threads used by the <EM>mt</EM>
            dispatching strategy.<br>
            <b>Does not apply to the <em>tpc</em> factory.</b>
          </TD>
        </TR>
        <!-- <TR NAME="ECDispatchingThreadFlags"> -->
        <TR>
          <td><code>-ECDispatchingThreadFlags</code>
            <em>thread_flags</em><b>:</b><em>thread_priority</em>
            </td>
          <td>
            Provide flags and priority used for creation of
            dispatching threads.<br>
            <em>thread_flags</em> is a set of
            <code>THR_</code> flags separated by the vertical bar
            ('|'), e.g.,
            <code>THR_BOUND|THR_NEW_LWP|THR_SCOPE_SYSTEM</code>.
            <br>
            <em>thread_priority</em> is a numeric value indicating the
            desired priority at which the thread should be created.
            No range checking is performed on the value prior to
            passing to the thread creation function.  Also note that
            priorities are platform-specific, so a valid value for a
            given set of flags on one platform may not work with the
            same flags on another platform.
          </tr>

        <!-- <TR  NAME="ECQueueFullServiceObject"> -->
        <tr>
          <td><code>-ECQueueFullServiceObject</code>
            <em>service_object_name</em>
            </td>
          <td>
            Used to specify the name/tag in the service configurator
            through which the RTEC should look for a "queue full
            service object".<br>
            <b>Will only have an effect on dispatch strategies that
            use <code>TAO_EC_Queue</code>.</b>
          </td>
        </tr>
        <!-- <TR NAME="ECFiltering"> -->
        <TR>
          <TD><CODE>-ECFiltering</CODE>
            <EM>consumer_filtering_strategy</EM>
          </TD>
          <TD>Select the filtering strategy used by the consumers.
            The <EM>null</EM> filtering strategy will build trivial
            filters for all consumers.
            The <EM>basic</EM> filtering strategy supports
            disjunction, conjunction, logical and, negation, bitmask,
            and timeout filters based on the subscriptions passed by
            the consumer during the connect call. It only supports limited
            nesting of filter groups.
            The <EM>prefix</EM> filtering strategy supports
            all filter types that the <EM>basic</EM> strategy does
            and allows unlimited nesting of filter groups.
            When using the <EM>prefix</EM> strategy, the source field of the
            group filter must specify the number of children in the group.
            The <EM>priority</EM> filtering strategy  (sched factory only)
            supports the same
            features as the <EM>basic</EM> filtering strategy, but it
            also collaborates with the scheduling service to build the
            dependency graph.
          </TD>
        </TR>

        <!-- <TR NAME="ECSupplierFiltering"> -->
        <TR>
          <TD><CODE>-ECSupplierFiltering</CODE>
            <EM>supplier_filtering_strategy</EM>
          </TD>
          <TD>The event channel can also perform some filtering close
            to the suppliers by minimizing the number of consumers
            that are tested for given event.
            If the strategy is <EM>null</EM> then a global collection
            of consumers is maintained and each event is filtered by
            each consumer.
            If the strategy is <EM>per-supplier</EM> then the EC uses
            the supplier publications and the consumer subscriptions
            to determine which consumers could potentially be
            interested in events for each supplier.
            This set of consumers is usually smaller than the complete
            set and it is thus faster to traverse it, but keeping more
            collections of consumers increases the connection and
            disconnection time as well as the memory requirements.
          </TD>
        </TR>

        <!-- <TR NAME="ECTimeout"> -->
        <TR>
          <TD><CODE>-ECTimeout</CODE>
            <EM>timeout_strategy</EM>
          </TD>
          <TD>A consumer can request that the event channel generate
            periodic or oneshot timeout events.
            This option controls the strategy to generate the
            timeouts,
            using <EM>reactive</EM> the same reactor used for the ORB
            is used by the event service.
            The <EM>priority</EM> strategy  (sched factory only) uses a
            prioritized group of
            threads, timeouts with higher rate are generated by
            threads of higher priority.
            <BR><B>NOTE: The <EM>priority</EM> strategy is not
              implemented</B>
          </TD>
        </TR>

        <!-- <TR NAME="ECObserver"> -->
        <TR>
          <TD><CODE>-ECObserver</CODE>
            <EM>observer</EM>
          </TD>
          <TD>The event channel uses the Observer pattern to report
            changes in the subscriptions and publications of its
            suppliers and consumers; this is especially useful in the
            implementation of event channel gateways.
            The user can disable this feature by selecting the
            <EM>null</EM> strategy;
            whereas the <EM>basic</EM> strategy provides a simple, yet
            efficient implementation. <EM>reactive</EM> provides a
            strategy in which an observer that is unreachable is removed
            from the observer list.
            <BR><B>NOTE:<B> The default is to have the feature disabled.
          </TD>
        </TR>

        <!-- <TR NAME="ECScheduling"> -->
        <TR>
          <TD><CODE>-ECScheduling</CODE>
            <EM>scheduling_strategy</EM>
          </TD>
          <TD>The event channel can collaborate with the scheduling
            service to build the dependency list between the consumers
            and the suppliers.
            If the <EM>null</EM> scheduling strategy is selected this
            feature is disabled,
            the <EM>priority</EM> strategy (sched factory only) enables this feature.
            <BR><B>NOTE:<B> The default is to have the feature disabled.
          </TD>
        </TR>

        <!-- <TR NAME="ECProxyConsumerLock"> -->
        <TR>
          <TD><CODE>-ECProxyConsumerLock</CODE>
            <EM>lock_type</EM>
          </TD>
          <TD>Select the lock type (<EM>null</EM>, <EM>thread</EM> or
            <EM>recursive</EM>) to synchronize access to the
            ProxyPushConsumer state.
          </TD>
        </TR>

        <!-- <TR NAME="ECProxySupplierLock"> -->
        <TR>
          <TD><CODE>-ECProxySupplierLock</CODE>
            <EM>lock_type</EM>
          </TD>
          <TD>Select the lock type (<EM>null</EM>, <EM>thread</EM> or
            <EM>recursive</EM>) to synchronize access to the
            ProxyPushSupplier state.
          </TD>
        </TR>

        <!-- <TR NAME="ECUseORBId"> -->
        <TR>
          <TD><CODE>-ECUseORBId</CODE>
            <EM>orbid</EM>
          </TD>
          <TD>Set the name of the ORB used by the event service, only
            useful in applications that create multiple ORBs and
            activate the event service in one of them.
          </TD>
        </TR>

        <!-- <TR NAME="ECConsumerControl"> -->
        <TR>
          <TD><CODE>-ECConsumerControl</CODE>
            <EM>policy</EM>
          </TD>
          <TD>Select the consumer control policy (<EM>null</EM> or
            <EM>reactive</EM>) to detect and discard broken consumers.
          </TD>
        </TR>

        <!-- <TR NAME="ECSupplierControl"> -->
        <TR>
          <TD><CODE>-ECSupplierControl</CODE>
            <EM>policy</EM>
          </TD>
          <TD>Select the supplier control policy (<EM>null</EM> or
            <EM>reactive</EM>) to detect and discard broken suppliers.
          </TD>
        </TR>

        <!-- <TR NAME="ECConsumerControlPeriod"> -->
        <TR>
          <TD><CODE>-ECConsumerControlPeriod</CODE>
            <EM>period</EM>
          </TD>
          <TD>Set the period (in microseconds) used by the reactive
            consumer control policy (set <EM>ECConsumerControl</EM> to
            <EM>reactive</EM>) to poll the state of the consumers.
            When set to 0 there is no polling but the
            reactive strategy is in place.
          </TD>
        </TR>

        <!-- <TR NAME="ECSupplierControlPeriod"> -->
        <TR>
          <TD><CODE>-ECSupplierControlPeriod</CODE>
            <EM>period</EM>
          </TD>
          <TD>Set the period (in microseconds) used by the reactive
            supplier control policy (set <EM>ECSupplierControl</EM> to
            <EM>reactive</EM>) to poll the state of the suppliers.
            When set to 0 there is no polling but the
            reactive strategy is in place.
          </TD>
        </TR>

        <!-- <TR NAME="ECConsumerControlTimeout"> -->
        <TR>
          <TD><CODE>-ECConsumerControlTimeout</CODE>
            <EM>timeout</EM>
          </TD>
          <TD>Set the timeout period (in microseconds) used by the reactive
            consumer control policy (set <EM>ECConsumerControl</EM> to
            <EM>reactive</EM>) to detect a timeout when polling the state
            of the consumers.
          </TD>
        </TR>

        <!-- <TR NAME="ECSupplierControlTimeout"> -->
        <TR>
          <TD><CODE>-ECSupplierControlTimeout</CODE>
            <EM>timeout</EM>
          </TD>
          <TD>Set the timeout period (in microseconds) used by the reactive
            supplier control policy (set <EM>ECSupplierControl</EM> to
            <EM>reactive</EM>) to detect a timeout when polling the state
            of the suppliers.
          </TD>
        </TR>

        <!-- <TR NAME="ECProxyPushConsumerCollection"> -->
        <TR>
          <TD><CODE>-ECProxyPushConsumerCollection</CODE>
            <EM>flag[:flags]</EM>
          </TD>
          <TD><P>Configure the data structure and strategies used to
              implement collections of
              <CODE>ProxyPushConsumers</CODE>.
              The argument is a colon separated list of flags, with
              the following semantics:
              <TABLE BORDER="1" CELLSPACING="2" CELLPADDING="0">
              <TR><TH>Flag</TH><TH>Description</TH>
              </TR>
              <TR>
                <TD>MT</TD>
                <TD>Use regular mutexes and/or condition
                  variables for serialization.
                </TD>
                </tr>
              <TR>
                <TD>ST</TD>
                <TD>Use null mutexes and/or condition
                  variables for serialization.
                </TD>
                </tr>
              <TR>
                <TD>LIST</TD>
                <TD>Implement the collection using an ordered list,
                  fast for iteration (i.e. during event dispatching),
                  but slow for insertion and removal (i.e. when
                  clients connect and disconnect from the EC).
                </TD>
                </tr>
              <TR>
                <TD>RB_TREE</TD>
                <TD>Implement the collection using a Red-Black tree,
                  slow for iteration (i.e. during event dispatching),
                  but fast for insertion and removal (i.e. when
                  clients connect and disconnect from the EC).
                </TD>
                </tr>
              <TR>
                <TD>IMMEDIATE</TD>
                <TD>Threads block until they can execute a change on
                  the data structure, the system must use other
                  approaches to guarantee that the iterators are not
                  invalidated during event dispatching.  For example,
                  use a separate dispatching thread.  Using this option
                  with the reactive values for any of the
                  -ECSupplierControl, -ECConsumerControl, or
                  -ECDispatching options may cause deadlocks.
                </TD>
                </tr>
              <TR>
                <TD>COPY_ON_READ</TD>
                <TD>Before initiating an iteration to dispatch events
                  (or similar tasks) a copy of the complete collection
                  is performed.
                  This solves most of the synchronization problems,
                  but introduces a significant source of overhead and
                  priority inversions on the critical path.
                </TD>
                </tr>
              <TR>
                <TD>COPY_ON_WRITE</TD>
                <TD>Similar to the previous one, but the copy is only
                  performed when needed.
                </TD>
                </tr>
              <TR>
                <TD>DELAYED</TD>
                <TD>Threads that need to change the collection can
                  detect if that change will invalidate iterators used
                  by other threads.
                  If so, the thread posts the change on a queue that
                  is executed once the collection is no longer in
                  use.
                </TD>
              </TR>
              </TABLE>
            </P>
          </TD>
        </TR>

        <!-- <TR NAME="ECProxyPushSupplierCollection"> -->
        <TR>
          <TD><CODE>-ECProxyPushSupplierCollection</CODE>
            <EM>flag[:flags]</EM>
          </TD>
          <TD><P>Configure the data structure and strategies used to
              implement collections of <CODE>ProxyPushSupplier</CODE>
              objects.
              Use the same arguments as with the
              <CODE>ECProxyPushConsumerCollection</CODE> option.
            </P>
          </TD>
        </TR>

        <!-- <TR NAME="ECConsumerValidateConnection"> -->
        <TR>
          <TD><CODE>-ECConsumerValidateConnection</CODE>
            <EM>validate_connection: 0 | 1</EM>
          </TD>
          <TD>When this option is set the connection from the Event Channel
            to the consumer will be created during the connect of the
            consumer, just before the consumer is added to the consumer
            list. By default
            the Event Channel will create the connection to the consumer at
            the moment the first event is pushed to the consumer.
            When the network is heavily loaded during this connect and a new event
            is pushed before the connection is established, a new create connection
            request is done. When having very high connection establishment
            time (for example running on a WAN) and an interval that is much
            smaller than the connection establishment time it is wise to
            set this option. Else you get dozens of new connection request
            that can result in a stack overflow. Another option is to use BiDIR
            GIOP so that there is only one connection between Rtec and consumer
            but for this the Rtec and the consumer must be changed to set the
            BiDIR Policy, this is not implemented at this moment.
          </TD>
        </TR>

      </TABLE>
    </P>

    <H3>The constructor</H3>

    <P>The <CODE>TAO_EC_Event_Channel</CODE> class implements the
      <CODE>RtecEventChannelAdmin::EventChannel</CODE> interface;
      this class takes one mandatory and two optional parameters in
      its constructor:
    </P>

<PRE>
  TAO_EC_Event_Channel (const TAO_EC_Event_Channel_Attributes& attributes,
                        TAO_EC_Factory* factory = 0,
                        int own_factory = 0);
</PRE>

    <P>The <CODE>factory</CODE> is an optional parameter to override
      the default strategy factory used by the event channel,
      the event channel will destroy the factory if the
      <CODE>own_factory</CODE> argument is true.
    </P>

    <P>The <CODE>attributes</CODE> parameter can be used to fine tune
      some of the algorithms and strategies used by the event channel,
      the default values are probably OK for most applications.
      Notice that the attributes include the POA used to activate the
      ConsumerAdmin, SupplierAdmin, ProxyPushConsumer and
      ProxyPushSupplier objects;
      these POAs must have the <CODE>IMPLICIT_ACTIVATION</CODE> and the
      <CODE>SYSTEM_ID</CODE> policies (as the RootPOA does).
    </P>

    <P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0">
        <TR><TH>Attribute</TH><TH>Description</TH></TR>

        <TR><TD><CODE>consumer_reconnect</CODE></TD>
          <TD>If the attribute is not zero then the same consumer can
            call <CODE>connect_push_consumer</CODE> on its
            ProxyPushSupplier multiple times to change its
            subscriptions;
            this is usually more efficient that disconnecting and
            connecting again.
          </TD>
        </TR>

        <TR><TD><CODE>supplier_reconnect</CODE></TD>
          <TD>If the attribute is not zero then the same supplier can
            call <CODE>connect_push_supplier</CODE> on its
            ProxyPushConsumer multiple times to change its
            publications;
            this is usually more efficient that disconnecting and
            connecting again.
          </TD>
        </TR>

        <TR><TD><CODE>busy_hwm</CODE></TD>
          <TD>When the delayed flag is set on proxy collections,
            this flag controls the maximum
            number of threads that can simultaneously iterate over the
            collection before blocking.
            It can be used to avoid starvation in delayed updates on
            the collection.
          </TD>
        </TR>

        <TR><TD><CODE>max_write_delay</CODE></TD>
          <TD>When the delayed flag is set on proxy collections,
            this flag controls the maximum
            number of threads that will initiate dispatching
            <B>after</B> a change has been posted.
            Any thread after that is blocked until the operations are
            performed.
            It can be used to completely stop starvation of delayed
            updates on the collection.
          </TD>
        </TR>

        <TR><TD><CODE>scheduler</CODE></TD>
          <TD>Most configurations of the real-time event channel do
            not require an scheduler.
            If any of the strategies that require an scheduling
            service is selected then this attribute should be set
            appropriately.
          </TD>
        </TR>

        <TR><TD><CODE>supplier_poa</CODE></TD>
          <TD>The POA used by the event channel to activate SupplierAdmin
            and SupplierProxy objects.
          </TD>
        </TR>

        <TR><TD><CODE>consumer_poa</CODE></TD>
          <TD>The POA used by the event channel to activate ConsumerAdmin
            and ConsumerProxy objects.
          </TD>
        </TR>

        <TR><TD><CODE>disconnect_callbacks</CODE></TD>
          <TD>If not zero, then the event channel sends disconnect
            callbacks when a disconnect method is called on a Proxy.
            For example, if a consumer calls
            disconnect_push_supplier() on its proxy the EC
            invokes disconnect_push_consumer() on the consumer.
            An analogous call is also made for suppliers when this
            attribute is set.
            By default, these callbacks are not made in this situation.
          </TD>
        </TR>
      </TABLE>
    </P>

    <H3>Configuring the IIOP Gateway</H3>

    <P>The <CODE>TAO_EC_Gateway_IIOP_Factory</CODE> is the factory for
      the <CODE>TAO_EC_Gateway_IIOP</CODE> class. This factory can be
      used to configure the settings of the IIOP Gateway using the
      svc.conf file. The contents looks like this:
    </P>

<PRE>
# Comments go here...
# More comments if you want to...
static EC_Gateway_IIOP_Factory "-ECGIIOPConsumerECControl null ....."
</PRE>

    <P>All the IIOP Gateway factory options start with
      <CODE>-ECGIIOP</CODE></P>

    <P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0">
        <TR>
          <TH>Option</TH>
          <TH>Description</TH>
        </TR>

        <!-- <TR NAME="ECGIIOPConsumerECControl"> -->
        <TR>
          <TD><CODE>-ECGIIOPConsumerECControl</CODE>
            <EM>policy</EM>
          </TD>
          <TD>Select the consumer ec control policy (<EM>null</EM> or
            <EM>reactive</EM> or <EM>reconnect</EM>) to detect and handle
             broken consumer ec's.
          </TD>
        </TR>
        <!-- <TR NAME="ECGIIOPConsumerECControlPeriod"> -->
        <TR>
          <TD><CODE>-ECGIIOPConsumerECControlPeriod</CODE>
            <EM>period</EM>
          </TD>
          <TD>Set the period (in microseconds) used by the reactive and reconnect
            consumer ec control policy (set <EM>ECGIIOPConsumerECControl</EM> to
            <EM>reactive</EM> or <EM>reconnect</EM>) to poll the state of the consumer ec.
            When set to 0 there is no polling but the
            reactive strategy is in place.
          </TD>
        </TR>

        <!-- <TR NAME="ECGIIOPConsumerECControlTimeout"> -->
        <TR>
          <TD><CODE>-ECGIIOPConsumerECControlTimeout</CODE>
            <EM>timeout</EM>
          </TD>
          <TD>Set the timeout period (in microseconds) used by the reactive and reconnect
            consumer ec control policy (set <EM>ECGIIOPConsumerECControl</EM> to
            <EM>reactive</EM> or <EM>reconnect</EM>) to detect a timeout when polling the state
            of the consumer ec.
          </TD>
        </TR>

        <!-- <TR NAME="ECGIIOPUseORBId"> -->
        <TR>
          <TD><CODE>-ECGIIOPUseORBId</CODE>
            <EM>orbid</EM>
          </TD>
          <TD>Set the name of the ORB used by the event gateway, only
            useful in applications that create multiple ORBs and
            activate the gateway in one of them.
          </TD>
        </TR>

        <!-- <TR NAME="ECGIIOPUseTTL"> -->
        <TR>
          <TD><CODE>-ECGIIOPUseTTL</CODE>
            <EM>use_ttl: 0 | 1</EM>
          </TD>
          <TD>Set whether the IIOP Gateway uses the TTL or not.
            This is 1 by default. When set to 0 make sure that
            no recursive structure is build between ec's, else an
            event can keep looping for ever. Useful when there are no
            recursive structures and we want the gateway to
            transfer all events independent of their TTL because suppliers
            can be unaware about the maximum number of hops. In case
            this option is 0, the TTL in the event isn't decremented
            by the gateway also.
          </TD>
        </TR>

        <!-- <TR NAME="ECGIIOPUseConsumerProxyMap"> -->
        <TR>
          <TD><CODE>-ECGIIOPUseConsumerProxyMap</CODE>
            <EM>use_consumer_proxy_map: 0 | 1</EM>
          </TD>
          <TD>Set whether the IIOP Gateway uses a map with a proxy
            push consumer for each unique source id or not. This is 1
            by default meaning that a map is used. When set to 0 the
            gateway will just use one proxy push consumer to push
            events to the consumer ec. This options is useful when
            a lot of different source id's are used but there is no
            need for a different proxy push consumer for each source id.
            Setting this option to 0 then improves the performance.
          </TD>
        </TR>
      </TABLE>
    </P>

    <H3>The commandline arguments</H3>

    The Event_Service executable has several commandline arguments you can use.
    The following arguments are available.

    <P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0">
        <TR>
          <TH>Option</TH>
          <TH>Description</TH>
        </TR>

        <!-- <TR NAME="-d"> -->
        <TR>
          <TD><CODE>-n</CODE>
            <EM>service_name</EM>
          </TD>
          <TD>The name with which the Event Service registers itself in the
    Naming Service.
          </TD>
        </TR>
        <!-- <TR NAME="-o"> -->
        <TR>
          <TD><CODE>-o</CODE>
            <EM>ior_file_name</EM>
          </TD>
          <TD>The file to which the IOR of the Event Service will be written.
          </TD>
        </TR>

        <!-- <TR NAME="-p"> -->
        <TR>
          <TD><CODE>-p</CODE>
            <EM>pid_file_name</EM>
          </TD>
          <TD>The process id of the Event Service will be written to this
          file
          </TD>
        </TR>

        <!-- <TR NAME="-q"> -->
        <TR>
          <TD><CODE>-q</CODE>
            <EM>ec_object_id</EM>
          </TD>
          <TD>The object ID for the Event Channel that will be used
          when a Persistent IOR is generated
          </TD>
        </TR>

        <!-- <TR NAME="-b"> -->
        <TR>
          <TD><CODE>-b</CODE>
            <EM></EM>
          </TD>
          <TD>Use BiDIR GIOP
          </TD>
        </TR>

        <!-- <TR NAME="-x"> -->
        <TR>
          <TD><CODE>-x</CODE>
            <EM></EM>
          </TD>
          <TD>Don't register the Event Service to the Naming Service
          </TD>
        </TR>

        <!-- <TR NAME="-s"> -->
        <TR>
          <TD><CODE>-s</CODE>
            <EM>global|local|none</EM>
          </TD>
          <TD>Which scheduler should be used. The default is <CODE>none</CODE>.
          With <CODE>local</CODE> an in process scheduler is created. With
          <CODE>global</CODE> a scheduler is retrieved from the Naming Service
          </TD>
        </TR>
      </TABLE>
    </P>

    <P><HR><P>

      Back to the TAO <A HREF="index.html">components documentation</A>.

      <!--#include virtual="/~schmidt/cgi-sig.html" -->

<!--    <address><a href="mailto:coryan@cs.wustl.edu">Carlos O'Ryan</a></address>-->
<!-- Created: Thu Jul  1 21:44:28 CDT 1999 -->
<!-- hhmts start -->
Last modified: Tue Oct 18 13:13:54 CDT 2005
<!-- hhmts end -->
  </body>
</html>
